Computer System and Method for Message Routing

ABSTRACT

Message routing techniques include use of at least one controller module configured to maintain a graph. The graph defines communication relations between a plurality of message communication modules. Each communication relation defines a particular message type for a particular pair of modules. The plurality of message communication modules includes a first module configured to receive a message wherein the received message has a message type and is associated with least one pre-condition. Upon verification of an acceptance condition of the at least one pre-condition the received message is accepted if the acceptance condition is fulfilled. Upon verification of a generating condition of the at least one pre-condition, the first module generates a generated message directed to at least a second module or an external data consumer in accordance with the graph if the generating condition is fulfilled.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to European Patent Application No.EP15164156, filed Apr. 18, 2015, titled “COMPUTER SYSTEM AND METHOD FORMESSAGE ROUTING” and is a continuation of U.S. patent application Ser.No. 15/130,599 filed on Apr. 15, 2016, entitled “COMPUTER SYSTEM ANDMETHOD FOR MESSAGE ROUTING”, which are incorporated herein by referencein their entirety.

TECHNICAL FIELD

The present description generally relates to electronic data processing,and more particularly, relates to methods, computer program products andsystems for keeping control of data.

BACKGROUND

A general problem in networked computer systems is to keep control ofdata in such a way that the creator or owner of such data can determinewho may use the data for which purpose. Security solutions for complexevent processing systems provide confidentiality of data, authorizationof network participants as well as encryption of event data. Inparticular, public key infrastructures are applied to complex eventprocessing (CEP) systems using a publish/subscribe architecture in orderto provide confidentiality of data, authorization of networkparticipants as well as encryption of event data.

In some existing CEP systems, a problem arises when data being used isgathered from large quantities of external entities and people with norelationship to the organization using the data. For example, inupcoming initiatives such as Smart Cities, large quantities of data aregathered from various sources such as public infrastructures and privatedata (e.g., households' energy and water consumption, location data, orshopping behavior). The scale of such systems makes it very hard toimplement a scheme where citizens and other third parties can explicitlydetermine how their private data being gathered from their homes is tobe utilized, and prevent the misuse and access from unintended entities.

SUMMARY

The present description describes an approach providing more flexibilityto define scalable control mechanisms for data when flowing from datasources to data sinks so that misuse and access from unintended entitiescan be prevented but specific aggregate use of data by third parties canbe allowed under specific circumstances.

Data owners are given the ability to specify the data granularity(frequency, precision, resolution) and to specify if their data shall becorrelated with other sources of information. Further, data owners aregiven the possibility of specifying whether their data shall be used inunforeseen or exceptional cases or under specific conditions.

User specific data can be useful to optimize a technical process such asthe control of energy provisioning of households or the control oftechnical equipment used for traffic management. A problem is that suchdata typically is tied to an individual or a group of individuals (e.g.,one or more persons in a household or in a car). Therefore, theindividual person (user) may be interested in protecting privacy of hisor her data whereas the user may be prepared to allow use of the data byother parties under certain conditions. Therefore, there is a technicalproblem to provide a system which allows an individual user to keepcontrol over data provided to computer systems or computer networkswhereby the system or network is scalable with regards to the number ofusers and the amount of data provided the users.

The problem is solved by a computer system which receives data from oneor more data sources through one or more inbound interface modules. Thereceived data can be analyzed by one or more complex event processingmodules to detect whether a predefined event condition is fulfilled bythe received data. One or more controller modules manage communicationrelationships between the modules. The communication is based on messageexchange. The controller module(s) know(s) the load of each moduleinstance and can therefore balance the load of each module by checkingwhether an existing module instance would exceed its processing capacityby processing a new event type.

Data received by the interface inbound module can result in a messagerelated to a specific data set or to aggregates of multiple data sets ina single message. The one or more controller modules are configured tocontrol whether such a message is allowed to be generated at all in thesystem by checking predefined pre-conditions which define under whichcircumstances such a message creation with the data provider'sconstraints (e.g., data privacy constraints) is allowed. Such apre-condition may include at least one static rule or event that musthave occurred before the corresponding message can be generated. Thecontroller module registers queries for checking correspondingpre-conditions with the complex event processing module. If such apre-condition is detected and forwarded by the inbound interface moduleto the complex event processing module. The complex event processingmodule can notify the controller module if the received messagecorresponds to a pre-condition. The controller module in response canthen update the configuration of the other modules accordingly.

In other words the controller module can add new communication relationsto the system configuration at runtime and notify all affected modulesaccordingly. Similarly, the controller module can remove communicationrelations from the system communication if they are not needed any moreand even shut down a module instance to avoid allocating more systemresources than are actually needed.

The configuration of communication relations can be defined by a graphstored in a graph database such as ORIENTDB (available from OrientTechnologies LTD, London, United Kingdom) or by any other database typesupporting the storage of Subject, Predicate and Object (e.g., throughthree column representations) related configuration data. Even a simplefile (text or binary data) can store the communication relations. Thecommunication relations define that a pre-condition check occurs foreach message to be exchanged between any one of the modules of thesystem.

The described system architecture allows an individual user to keepcontrol over data provided to the system by determining the respectiveuse of constraints as defined by the pre-conditions. For example, a usermay not allow a metering operator in an energy provisioning network toforward any information regarding the individual energy consumption ofhis or her household to the energy network operator unless the networkgets into an instable condition. In such an event the user can consentthat, for example, his or her data is used by the network operatoreither on a household basis or perhaps only at an aggregate levelaggregating all data of the households in a particular quartier. Thatis, the user keeps control of the data provided to the metering operatorand determines under which conditions which data may be used by thirdparties at which aggregation level.

In general, the computer system for message routing according to exampleembodiments can be described as pairs of communication modules which arecascaded or arranged in parallel. The system has at least one controllermodule configured to maintain a communication relations graph. The graphdefines communication relations between a plurality of messagecommunication modules. Each communication relation defines a particularmessage type for a particular pair of modules out of the plurality. Ingeneral, such a pair of communication modules includes a first and asecond communication module. The terms message communication module,communication module and module are used as synonyms hereinafter. Thecontroller module thereby is not a communication module in this sensebut is enabling the communication between such modules.

The first module is configured to receive a message wherein the receivedmessage has a message type and is associated with least onepre-condition. Upon verification of an acceptance condition of the atleast one pre-condition in accordance with the graph the receivedmessage is accepted if the acceptance condition is fulfilled. Further,upon verification of a generating condition of the at least onepre-condition in accordance with the graph, the first module generates agenerated message directed to at least a second module or an externaldata consumer in accordance with the graph (300) if the generatingcondition is fulfilled. The generated message can be identical to thereceived message in which case the generated message corresponds to aforwarding of the received message. The generated message may also be anew message (e.g., aggregated message) which is composed by using thedata of the received message together with further data of furtherreceived messages and computing a result (e.g., average data, sum ofdata, etc.)

The at least second module also implements the function of the firstmodule with regards to received messages. That is, when the secondmodule receives the generated message as the target module of the firstmodule (in accordance with the graph), the second module treats thegenerated message as received message and performs the same check andmessage generating steps as the first module. At least a further moduleis treated like the original at least second module in accordance withthe graph. That is, the at least second module uses the at least furthermodule (or the external data consumer) as the target for the messagewhich is now generated by the second module.

The message routing system can be iteratively expanded by adding suchpairs of modules and establishing the respective communication relationsin the graph. For example, the pairs of modules having a communicationrelation can include the first module being an inbound interface moduleand the second module being a complex event processing module, apersistence module, or an analytics module. Further, the second modulecan be an outbound interface module and the first module can be acomplex event processing module, a persistence module, or an analyticsmodule. It is also possible, that the first and second modules are thesame. That is, the module is sending a message to itself. This may bethe case with complex event processing modules or analytics modules inwhich case a multi stage processing of data messages by the same moduleis enabled.

In order to enable a message flow from data sources to data consumers atleast one message communication module is configured to receive amessage from an external data source, at least one message communicationmodule is configured to process the received message by using complexevent processing, and at least one message communication module isconfigured to forward the generated message to the external dataconsumer.

In one embodiment at least one message communication module isconfigured to persist (store) the received message. In this embodiment,the computer system can allow data consumers to query historic datawhich were persisted based on earlier received messages.

In one embodiment, the at least one controller module may be furtherconfigured to register one or more queries with at least one of themessage communication modules for detecting a particular eventassociated with a particular pre-condition, the particular pre-conditionbeing associated with a particular pair of communication modules. Forexample, CEP modules can be used such event detection tasks. Thecontroller module may then receive a notification from the at least oneof the message communication modules when the particular event isdetected and can activate a particular communication relation betweenthe particular pair of message communication modules when the particularpre-condition is fulfilled. When the particular pre-condition ceases tobe fulfilled the at least one controller module can deactivate theparticular communication relation between the particular pair of messagecommunication modules again. This allows the controller module to createand terminate communication relations between modules on the fly todynamically react to certain events which are relevant to pre-conditionsas defined by users of the data sources. A flexible and granularhandling of data privacy constraints in relation to individual data istherefore enabled by example embodiments.

In one embodiment, the at least one controller module can receive amodule identifier from a communication module being started for thefirst time. The controller can then create a module representation forthe first time started communication module in the communicationrelations graph and send controller module configuration data to thefirst time started communication module. The first time started moduleis then aware of the controller module by which it is managed. Thecontroller module can further generate communication relations for thefirst time started communication module according to predefined loadmetrics and switch communication relations in the graph from apreviously existing communication module to the first time startedcommunication module for balancing the load based on the load metrics incase of a re-scaling event. In this embodiment, the scalability of themessage routing system is improved by adding additional communicationmodules duplication the function of already existing modules on the flywhich can then handle parts of the message flow if the load for thepreviously existing modules becomes too high according to the loadmetrics. The predefined load metrics can include the number ofcommunication relations of one or more communication modules of the samekind, the frequency of sent or received messages, the physical resourcesof a communication module, the response time of a communication module,the latency between different communication modules, and/or a failure ofa module. Switching communication relations may include cloning affectedoutbound interface communication relations of the previously existingcommunication module for the first time started communication module,switching affected inbound interface communication relations from thepreviously existing communication module for the first time startedcommunication module, and removing affected outbound interfacecommunication relations of the previously existing communication module.

The described functions and method steps of the message routing systemcan be performed by the respective modules of the system when the systemis executing a corresponding computer program product which includes aset of computer readable instructions stored in a memory of the systemand executed by at least one processor of the system.

Further aspects will be realized and attained by means of the elementsand combinations particularly depicted in the appended claims. It is tobe understood that both, the foregoing general description and thefollowing detailed description are exemplary and explanatory only andare not restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram of a computer system for messagerouting according to an embodiment.

FIG. 2 is a simplified graph which illustrates communication relationsbetween communication modules of the computer system.

FIG. 3 is a simplified flow chart of a computer-implemented method formessage routing being executed by the computer system when running acorresponding computer program product according to one embodiment.

FIG. 4 is a swim line diagram illustrating message flow betweencommunication modules according to specific example embodiments.

FIG. 5 is a simplified flow chart of a method which enables loadbalancing in one embodiment of the computer system and improvesscalability of the message routing system.

FIG. 6 illustrates an example of a simplified communication relationsgraph used for load balancing in a message routing system according toan example embodiment.

FIG. 7 is a diagram that shows an example of a computer device and amobile computer device, which may be used with the techniques describedhere.

DETAILED DESCRIPTION

Topics like Smart City, District Energy Management, Smart Home andIntelligent Traffic Management are increasingly making use of managementand real time analytics of large amounts of data created by anincreasing number of sensors. This leads to problems regarding the realtime capability of systems in view of the large amount of data andregarding the privacy of personal data belonging to individuals.

For example, due to a more and more distributed and volatile energyproduction, the management of the energy grid will need more informationabout the energy needs of individuals to ensure and keep grid stability.Traffic management will also require more information of the actingindividuals to improve the whole system. Typically, this comes at theprice of penetrating the personal privacy of individuals. In certainsituations and under certain conditions, individuals may be willing toprovide personal data to third parties to gain benefits. For example, anindividual may achieve an added value for himself (e.g., optimization ofone's own system, reduction of one's own cost, immediate assistance incase of emergency situations, etc.) or the individual may contribute toraise a common benefit (e.g., improved handling of emergency situations,improving and stabilizing the public infrastructure like electricitygrids and traffic roads, etc.). The following scenarios disclosed inthis document provide examples for the use of various embodiments.

FIG. 1 is a simplified block diagram of a computer system 100 formessage routing according to an example embodiment. Further, referencewill be made to FIG. 2 showing a simplified graph 300 which illustratescommunication relations between communication modules of the computersystem 100.

In the example of FIG. 1 the computer system 100 has one or morecontroller modules 110, one or more inbound interface modules 130, oneor more complex event processing (CEP) modules 140, one or morepersistence modules 150, and one or more outbound interface modules 160.Communication relations between pairs of modules are defined by thegraph 300 (cf. FIG. 2) which is maintained by the one or more controllermodules 110. The graph 300 has representations 330, 340, 350, 360 of therespective modules 130, 140, 150, 160. The computer system can alsoinclude further modules (e.g., an analytics module) at the same level asthe CEP and persistence modules 140, 150. That is, further dataprocessing modules may be plugged in between the inbound and outboundinterface modules 130, 160. The following example pairs of modules canhave a communication relation: an inbound interface module 130, 330 anda complex event processing module 140, 340; an inbound interface module130, 330 and a persistence module 150, 350; a complex event processingmodule 140, 340 and an outbound interface module 160, 360; and apersistence module 150, 350 and an outbound interface module 160, 360.Thereby, the one or more inbound interface modules 130, 330 areconfigured to receive messages from the external data sources 210, 310.The one or more CEP modules 140, 340 are configured to process thereceived messages by using complex event processing. CEP modules allowthe detection, filtering, aggregation and creation of events. The CEPmodule(s) can be realised with existing off the shelf Complex EventProcessing Engines like ESPER (available from EsperTech Inc., Wayne, NJUSA) or APAMA (available from Software AG, Darmstadt, Germany) andadditional interfaces that realize the communication with the controllermodule(s). Main functions are the registration of new message/eventtypes, the registration of new queries to select specific events, eventaggregations and complex events.

The one or more persistence modules 150, 350 are configured to persist(store) the received messages in respective memory portions of thecomputer system and can provide access to historic data/events. The oneor more outbound interface modules 160, 360 are configured to forwardgenerated messages to external data consumers 220, 320.

Turning briefly to FIG. 2, the graph 300 illustrates possiblecommunication relations between the various communication modules. Eachcommunication module can be configured to receive messages 301 (dashedarrows) and to generate messages 302 and send (straight line arrows) itto a further communication module. Each module can accept a receivedmessage 301 or ignore it dependent on a pre-condition 370 associated(dashed-dotted arrows) with the received message 301. FIG. 3 issimplified in that only one pre-condition 370 is shown. However, foreach module and for each accept or generate message decision a differentpre-condition can exist. The person skilled in the art will understandpre-condition 370 as a general representation of any potentialpre-condition relevant at the respective communication module for takingan accept or generate decision. If the corresponding pre-condition isfulfilled the respective communication module accepts/generates thereceived/generated message 301/302, respectively. A generated messagecan correspond to a forwarding of the received message but it can alsoresult in the creation of a new message. Thereby, each communicationmodule can receive the information necessary to take such decisions fromthe controller module. In other words, the controller module can sharethe knowledge about the communication relations graph 300 with the othercommunication modules to the extent that they are in possession of allnecessary information for taking the correct message routing decisions.Communication relations can be static or dynamic. That is, acommunication relation may always exist or it may be activated atruntime during the operation of the computer system dependent whensuddenly a certain pre-condition is fulfilled and it may be deactivatedagain when the pre-condition is not fulfilled anymore.

The embodiment of FIG. 1 is now described by using an exampleapplication scenario based on energy management of energy grids. Given,there are three households A, B and C, wherein each household isequipped with smart meter technology. A smart meter is usually anelectronic device that records consumption of electric energy inintervals of an hour or less and communicates that information atappropriate time intervals back to the utility for monitoring andbilling. Smart meters enable two-way communication between the meter anda central system. Smart meters typically can gather data for remotereporting (data to the energy provider). Such an advanced meteringinfrastructure enables two-way communications with the meter.

The meter operators (utility) receive data about the energy consumptionof the households for the purpose of billing. An energy provider may beinterested in detailed energy consumption data of each individualhousehold or even of individuals within the household. In this example,the energy provider provides data about the grid as data sources 210 tothe computer system 100. Further, the energy provider may request fromthe consumers (e.g., households A, B and C) to become data sources 210(e.g. A becomes data source 211, etc.) for the computer system 100 andto agree to the further use of their energy data collected by therespective smart meters by specifying to which extent the data can beused or consumed.

Besides A, B and C further data sources may exist either in the form ofother smart meters or in the form of further sensors which may provideto the computer system status information about the status of the energygrid. Such further sensors may be operated by data consuming entities(e.g., the energy provider itself) and the provided data may thereforenot be associated with constraints or pre-conditions at all.

In the example scenario, household A 211 agrees. Household B 21 n agreeswith the restriction, to only make use of its data if the whole energygrid is about to fail (i.e. the energy grid is in a critical unstablecondition). In addition, B prohibits that its data will be storedpermanently. Household C (not shown) agrees with the restriction, toonly make use of its data as an aggregate of the data sets of the otherhouseholds.

As a consequence of the household preferences and restrictionsrespective pre-conditions are configured by using one or more controllermodules or the 110 of the system. In the following scenario a singlecontroller module 110 is assumed. However, multiple controller modulesmay be used parallel for load balancing purposes. This will be explainedlater. The pre-conditions 370 may be configured by the households A, B,C or by the energy provider under the control of the consumers usingappropriate user interface means. For example, the computer system 100may provide a web service which allows the consumer(s) or energyprovider(s) to remotely access the controller module 110 and to supportthe creation of the respective pre-conditions 370 accordingly. Accordingto the above example scenario the following pre-conditions areconfigured in the one or more controller modules 110.

A mentioned no restrictions. Therefore no pre-condition needs to bedefined for data source 211. As a consequence, the controller module 110has the configuration definition: if data source=“A” AND messagetype=“data message”: allow all communication relations.

B mentioned the risk of grid failure and prohibits the storage of itsdata. Therefore the corresponding pre-conditions can be defined as:

-   -   1) if data source=“B” AND message type=“data message”: if an        event or forecast value is indicating a critical state of the        grid (e.g., the delta of total energy production and total        energy consumption is getting close to zero)), then allow all        communication relations; (In general, the critical state can be        determined based on one or more of technical parameters        indicating a technical situation in that the energy supply        system of the energy provider faces a critical situation (e.g.        total consumption approaching a percentage threshold of the        capacity, etc.)    -   2) if data source=“B” AND message type=“data message”:        persistence not allowed.

C mentioned, that it only agrees to the use of its data if its data isaggregated with data from other households. Therefore the preconditioncan be defined as: if data source=“C” AND message type=“data message”:aggregation only.

Upon the configuration of the pre-conditions, the controller module 110can create and/or maintain the graph 300 which defines communicationrelations between a plurality 120 of message communication modules 130,140, 150, 160 of the computer system 100. Each communication relationdefines a particular message type (e.g., data message, status message,etc.) for a particular pair of modules out of the plurality 120. Thegraph 300 can be stored in any appropriate data structure format in amemory portion of the computer system 100. A graph data structureincludes a finite (and possibly mutable) set of nodes or vertices,together with a set of ordered pairs of these nodes (or, in some cases,a set of unordered pairs). These pairs are known as edges or arcs. Anedge (x,y) is said to point from x to y. A graph data structure may alsoassociate to each edge an edge value, such as a symbolic label or anumeric attribute (e.g., the predicate of the relation). In the contextof the communication relation graph data structure the edges in thegraph represent the predicates (e.g., sends, receives, etc.) of therespective relations.

In the example scenario, the following communication relations can becreated in the graph 300. There are relations between the inboundinterface module 130, 330 and each household (data sources 210, 310).Further, there are relations between the inbound interface module 130,330 and the persistence module 150, 350 for messages received from A andC. B has an explicit pre-condition 2) preventing any persistence of itsdata. Therefore, no corresponding communication relation with thepersistence module is created for B.

Due to the pre-condition 1) of B, the controller module 110 creates twocommunication relations in the graph 300: a first communication relationbetween the inbound interface module 130 and the CEP module 140, and asecond one between the CEP Module 140 and itself. In addition, thecontroller module 110 registers one or more queries in the CEP Module140 to receive notifications if the pre-condition 1) of household B isfulfilled by a message or not. The registration of queries is disclosedin more detail in FIG. 6. The CEP may also receive messages/events fromother data sources than consumer related smart meters. For example, theenergy grid provider can continuously send data which indicate whetherthe grid is approaching a critical status. The CEP module can thenevaluate such events to detect the critical state based on predefinedcorresponding queries.

For example, the energy provider (data consumer) wants to make use ofthe provided data and configures the controller module 110 to send anotification if one of the households exceeds its average energyconsumption by 10%. The controller module 110 can check the respectivepre-conditions and perform the following actions:

-   -   It rejects the request of the energy provider for household C        since the query is not related to aggregate data of multiple        households (as allowed by the pre-condition of C).    -   It establishes the communication relations between the inbound        interface 130, 330 and CEP Module 140, 340 for messages of A and        B.    -   It creates relations between the CEP Module 140, 340 and the        outbound interface module 160, 360 for such notification        messages which are associated to the messages and pre-conditions        of the households A and B.

In operation, the smart meters (data sources 210, 310) of A, B and Csend energy consumption data having a message type “data message” whichare received 1100 by the inbound interfaces 130, 330. Further, theenergy provider sends data about the grid state (i.e. the technicalstatus if grid) to the inbound interfaces 130, 330. The inboundinterface module 130, 330 checks 1200 if any configured pre-condition370 includes an acceptance condition which would not be fulfilled by anyof the received messages 301. As no pre-condition is configured whichwould prevent the acceptance of the received messages, all data messagesare accepted by the inbound interface module 130, 330.

The inbound interface module then verifies 1300 if the pre-conditionsinclude generating conditions in accordance with the graph 300 whichtrigger the generation of generated messages 302 to further modules. Forexample, the pre-conditions of A and C allow persistence of therespective data. Therefore, the inbound interface generates 1400messages to forward the data received from the households A and C to thepersistence module 150, 350. In this case the generated message 302corresponds to the received message 301. That is, the received messageis simply forwarded to the destination communication module according tothe defined commination relation. There is no communication relationbetween the persistence module and the inbound interface for B. As aconsequence, the corresponding generating condition is not fulfilled formessages associated with B. There is no communication relation betweenthe inbound interface and the CEP module regarding data messagesoriginating from C.

Further, because A allowed all communication relations for datamessages, also data messages to be forwarded to the CEP Module 140, 340are generated 1400 by the inbound interface. The CEP module has acommunication relation with the inbound interface for household A andthere is no pre-condition configured for A which would prohibit thegeneration of the respective message. There is no pre-condition whichwould prevent the CEP module from accepting the forwarded messagesassociated with A. The CEP module 140, 340 can analyze the accepted datamessages associated with A and also generate messages according todetected events in accordance with the energy provider's request. Themessage generated by the CEP module corresponds to the notificationmessage for the energy provider (data consumer 320) and can be routed tothe data consumer 320 through the outbound interface module 160, 360 byapplying pre-condition checks 1200, 1300 iteratively 1500 to therespective modules.

In general, messages which are generated by CEP modules or analyticsmodules in response to a received message are typically not identical tothe received message. Rather, if allowed by the respectivepre-conditions, they may include aggregate data which is based on thereceived data message but which aggregates this data with the data offurther data messages (e.g., individual energy consumption 4 aggregatedinto a total energy consumption of a quartier). Of course, for theaggregate data message generation the respective pre-condition need tobe fulfilled.

At one point in time, the CEP module detects a critical grid state(e.g., delta of total energy production and total energy consumption isclose to 0) and the controller module 110 receives a correspondingnotification from the CEP module. Since this case is defined as apre-condition (pre-condition 1) of B, where B has waived his dataprivacy rights in favor of re-stabilizing the energy grid), thecontroller module 110 notifies the CEP module 140 to forward messages ofhousehold B to the outbound interface 160 (dynamically activating thecorresponding communication relation). The CEP module 140 now forwardsnotifications which are related to messages of B to the outboundinterface module 160. When the grid state data indicate a “normal” stateagain (that is, the delta of total energy production and total energyconsumption is significantly above 0), the controller module 110disables the previously activated communication relation between the CEPmodule and the outbound interface for messages associated with B. Thatis, the data privacy for data messages associated with B isautomatically enforced again by the computer system.

Further aspects will now be described in the context of a trafficmanagement scenario. The scenario includes three people A*, B* and C*individually traveling through a city wherein each one is driving avehicle. Driver A* drives a conventional car, whereas driver B* drivesan electric vehicle (EV). Driver C* is a truck driver. A*, B* and C* areusing a GPS based navigation system that is able to send various typesof information to one embodiment of the computer system 100. Theinformation may include information about the routes of the vehicles,the driving speed and the battery level in case of the EV. Therefore,the navigation systems and/or board computers of the vehicles are datasources 210, 310 to the computer system 100.

The municipal administration of the city asks A*, B* and C* if they arewilling to provide their data to the city's traffic management systemfor traffic optimization. Driver A* agrees. In addition to the municipaladministration, the local energy provider asks driver B* if she iswilling to provide information about the battery level and the locationof her EV for the purpose of estimating energy demand. B* agrees withthe restriction to only make use of her data if there is either atraffic jam in the city or an occurrence of an emergency situation or acritical energy grid state. In addition, B* prohibits that her data isstored permanently. C* agrees with the restriction to only make use ofhis data as an aggregate of data sets over all drivers. The followingpre-conditions are configured in the controller module 100 under thecontrol of A*, B* and C*.

A* mentioned no restrictions. Therefore no pre-condition needs to bedefined his navigation system as a new data source. The controllermodule 100 has the configuration definition:

-   -   if data source=A* AND message type=“navigation data”: allow all        communication relations.

B* mentioned the occurrence of traffic jams or critical grid states andshe prohibits the storage of her data. Therefore the preconditions canbe defined as:

-   -   1) if data source=B* AND message type=“navigation data”: if a        traffic jam is recognized in the city, then allow all        communication relations    -   2) if data source=B* AND message type=“navigation data”: on        occurrence of an emergency situation allow all communication        relations,    -   3) if data source=B* AND message type=“energy data”: on        occurrence of a critical energy grid state allow all        communication relations for energy data, and    -   4) if data source=B* AND message type=“*”: data persistence not        allowed.

C* mentioned, that he only agrees to the use of his data if his data isaggregated. Therefore the precondition can be defined as: if datasource=C* AND message type=“*”: only allow data aggregation.

Now, the following communication relations can be created in the graph300 by the controller module(s):

-   -   relations between the inbound interface(s) 130, 330 and each        vehicle's navigation system (data sources) 210, 310,    -   relations between the inbound interface(s) 130, 330 and the        persistence module(s) 150, 350 for messages originating from A*        and C*.    -   a relation between the CEP module(s) 140, 340 and itself        (controller module) in accordance with the pre-conditions 1),        2), and 3) of B*. In addition, the controller module registers        queries in the CEP module to receive notifications if the        pre-condition 1), 2) or 3) of B* are fulfilled or cease to be        fulfilled.

If the city traffic management system wants to make use of the dataprovided by A*, B* and C*, for example, the controller module can beconfigured to send a notification if there are traveling too many carson a certain route. The controller module can check the pre-conditionsand perform the following actions:

-   -   It establishes the appropriate communication relations between        inbound interface 130, 330 and CEP module 140, 340 for the        messages of A* and B*.    -   It creates relations between the CEP module 140, 340 and the        outbound interface module 160, 360 for the notification messages        which are also associated to the messages and pre-conditions of        the navigation systems of A* and B*.    -   As the query takes an aggregate of data of multiple vehicles, it        also establishes the communication relations between the inbound        interface and CEP module for the messages of C*'s vehicle.

The local energy provider may want to know when the EVs in the city havea low battery level to estimate near future energy demand and places ofcharging. For this purpose the energy provider can configure thecontroller module to send notifications containing the location and thebattery level of the EV. The controller module can check thepre-conditions and perform the following actions:

-   -   It establishes an additional communication relation between the        CEP module 140, 340 and the outbound interface module 160, 360        for the notification messages which are also associated to the        messages and preconditions of the navigation system of B*.

In operation A*, B* and C* are on the road and their navigation systemsand/or board computers are sending their GPS-positions (navigationmessages) to the inbound interfaces. Further, the city trafficmanagement system sends data about the traffic status to the inboundinterfaces 130, 330. Navigation messages of the drivers A* and C* areforwarded to the persistence module. Messages of driver A* are forwardedto the CEP module 140, 340 and detected events can trigger the creationof a notification message which to be forwarded to the outboundinterface module 160, 360. According to the pre-conditions defined byB*, messages of driver B* are not forwarded.

Every time when the CEP module detects a traffic jam in the city (e.g.,a traffic jam in front of crossroad 247) the controller module willreceive a corresponding notification. Since this case is defined as apre-condition, the controller module notifies the inbound interface toforward messages of driver B* to the CEP module (to activate therelation). The CEP module now forwards notifications which are relatedto messages of driver B* to the outbound interface module related totraffic management system of the city.

When a critical grid state is detected, the controller module willreceive a notification. Since this case is defined as a pre-condition,the controller module notifies the inbound interface to forward messagesof driver B* to the CEP module to activate the communication relation.The CEP module now forwards notifications which are related to messagesof driver B* to the outbound interface module related to the energymanagement system of the local energy provider (data consumer).

At the moment when the incoming data signalizes no traffic jam orcritical grid state any more, the controller module disables thepreviously activated communication relations.

At any time, if the system (in detail the CEP module) detects theoccurrence of an emergency situation (e.g. a fire brigade operationneeds the best route to the incident location), the controller modulewill receive a notification. Since this case was defined as aprecondition, the controller module notifies the outbound interface toforward messages of driver B to the CEP module (to activate therelation), even if no traffic jam was detected at the same time. The CEPmodule now forwards notifications which are related to messages ofdriver B to the outbound interface module. When the incoming dataindicates that the emergency occurrence does not exist any longer, thecontroller module disables the previously activated communicationrelations.

FIG. 3 illustrates a flow chart of a computer-implemented method 1000for message routing being executed by the computer system when running acorresponding computer program product. The method 1000 is illustratedas an iterative process which describes steps performed by a firstcommunication module. The steps are then repeated in the same manner bya second communication module and further communication modules untilfinally the system boundary is reached and the message is routed to anexternal data consumer. Thereby, the maintaining step 1050 is a kind ofinitialization step to define the communication relations graph which isused by later steps of the method. Maintaining 1050 is not necessarilyrepeated with each iteration in method 1000 but is performed whenever aneed occurs for updating the graph. For example, when additionalcommunication modules are added to the message routing system for loadbalancing purposes (cf. FIG. 6), the graph is maintained by thecontroller module and the corresponding configuration updates are madeavailable to the communication modules (cf. FIG. 4).

A first (communication) module receives 1100 a message wherein thereceived message has a message type and is associated with at least onepre-condition. When the receiving step is performed for the first timethe first module typically corresponds to the inbound interface whichreceives a message from an external data source. The message type canindicate, for example the structure of the messages, the key/value pairsor parameter types, a description of the event itself, etc. For example,energy data may have a structure different from navigation data whichmay result in different respective message types. A message beingassociated with a pre-condition means that the computer system hasknowledge of earlier defined conditions which can be applicable to thereceived message.

The first module then checks 1200 if the at least one pre-conditionincludes an acceptance condition which is fulfilled by the receivedmessage. In other words, the module can determine whether any knownpre-condition is configured in such a way that it applies to thereceived message. The information which is required for the check 1200is maintained 1050 by the controller module in the form of thecommunication relations graph and the pre-conditions. In other words,the controller module holds the configuration and orchestrates thecommunication modules of the computer system. The controller module cancontinuously update the communication modules with the information whichis relevant to each particular communication module for performing themessage checks. The configuration of the controller module allowsverifying if an external system is allowed to receive a particularmessage or the aggregate of multiple data sets in a message. Further, itallows verifying if a user is allowed to read, to combine and to analyzespecific data sets. If the acceptance condition is not fulfilled, thefirst module ignores 1250 the received message and waits for the nextmessage to be received.

If the acceptance condition is fulfilled, the received message isaccepted and a further check 1300 is performed (again by usinginformation from the controller module). The further check 1300 has thegoal to validate if the message is allowed to be subject to furtherprocessing by other communication modules. Therefore, the further checkis directed to a generating condition of at least one pre-conditionassociated with the accepted message. If the generating condition is notfulfilled the first module ignores 1350 the accepted message and waitsfor new messages to be received. In other words, messages that areinvolved in the message routing process need to fulfill a pre-conditionbefore the message can even be generated. The pre-condition itselfincludes at least one event that must have occurred before therespective message can be generated.

If the generating condition is fulfilled the first module generates 1400a generated message directed to at least a second module or an externaldata consumer in accordance with the graph maintained by the controllermodule. The second module as a target for the generated message can beidentified from the graph defining the communication relations betweenthe plurality of message communication modules. From this graph thefirst module can derive the target module for the generated message withthe respective message type. Generating such a message may simplyinclude the forwarding of the received message. For example, when theinbound interface receives and accepts a data message from a data sourceit may generate the generated message by simply forwarding the messageto the target module(s) (e.g., CEP module, persistence module, analyticsmodule, etc.). If the message generating module is a CEP module or ananalytics module, a totally new message may be generated based on thedata of the received message.

Once the generated message is received by the at least second module,the preceding steps can be iteratively repeated 1500 for further messagecommunication modules in that for each iteration the at least secondmodule is treated as the first module and at least a further module istreated as the at least second module in accordance with the graph. Thisiteration continuous until a last module (typically an outboundinterface module) of the computer system is reached wherein the lastmodule has a communication relation with the external data consumer. Inother words, if the second module corresponds to the CEP module, the CEPmodule performs the checking steps 1200, 1300 with regards to messagegenerated by the first module and now becoming the received message forthe CEP module. The CEP module can then generate a new message if the(by the CEP module) received and accepted message passes the furthercheck 1300. In compliance with the communication relations graph thegenerated message is then sent to a further communication module (e.g.,the CEP module itself or the outbound interface module) which is thenperforming the role of the first module and treating the generatedmessage again as a received message. A person skilled in the art canapply the iteration to any message communication module for any messagetype within the computer system for message routing.

FIG. 4 is a swim line diagram illustrating message flow betweencommunication modules according to specific example embodiments. Thevertical bars in FIG. 4 represent the following entities: U: user; DS:data source; IIM: inbound interface module; CM: controller module; CEPM:CEP module; PM: persistence module; OIM: outbound interface module; andDC: data consumer. Arrows between the entities represent messages beingsent from one entity to another entity. For better readability entitybars are interrupted (by dashed lines) when message arrows go across therespective entity. In the vertical dimension the swim line diagram isdivided into different areas. The area I (NPC) relates to messages inthe context of creating new pre-conditions. Area II (MP) relates tomessage processing where sub-area IIa relates to pre-condition detectionand sub-area IIb relates to event detection in cases where acommunication relation to a CEP module exists for real time processing.Sub-area IIc relates to message processing where a communicationrelation to a persistence module exists for storing data/messages. AreaQHD III relates to the querying of historic data.

Area I illustrates that a user U is sending message 1 to the controllermodule. Message 1 includes the information defining a pre-condition fora particular message type for the user. That is, the user determines bythis configuration how data which will be generated by the user's datasource DS will be handled by the various communication modules. Theconfigured pre-conditions allow the user to keep control of the dataprovided by the data source and decide about the later potential use ofthe data by other parties (data consumers). In response to the receivedmessage 1, CM sends message 2 to the CEPM. Message 2 causes the CEPM toregister queries for the received pre-conditions so that the CEPM cannotify CM once a registered pre-condition is fulfilled by receiveddata/events.

Area II illustrates that the DS associated with the user U sends message3 which is received by the IIM. In the following it is assumed thatboth, the acceptance and the generating conditions of the registeredpre-conditions are fulfilled by the received messages. In the example,the IIM generates message 4 (which can be identical to message 3) andforwards message 4 to the CEPM as an event. If the CEPM detects apre-condition associated with the received event (message 4) it sendsnotification message 5 back to the CM. The CM informs the othercommunication modules about the new detected pre-condition by generatingcorresponding configuration updated messages 6, 7, 8, 9 and sending themto the respective communication modules IIM, CEPM, PM, OIM. This enablesthe various communication modules to take real time accepting/generatingdecisions for messages based on the current configuration of thecommunication relations graph.

If a registered event is detected, the CEPM generates notificationmessage 10 which is sent to the OIM from where it is forwarded (message11) to the respective DC. If a communication relation exists between theIIM and PM, message 12 is forwarded to the PM.

In area III it is assumed that a DC sends query message 13 whichincludes a request for historic data stored in the PM. The OIM receivesthe message 13 and forwards the corresponding generated message 14 tothe PM. The PM retrieves the requested data and sends response message15 to the OIM from where generated message 16 is forwarded to therequesting DC thus satisfying the DC information request.

FIG. 5 is a simplified flow chart of a method 2000 which enables loadbalancing in one embodiment of the computer system 100 (cf. FIG. 1) andimproves scalability of the message routing system. Method 2000 can runbefore step 1100 of method 1000 (cf. FIG. 3) or it can run after step1400. When a particular one of the communication modules (e.g., inboundinterface, outbound interface, persistence, CEP, analytics) is started2100 for the very first time it can send 2200 an identifier token/objectto the controller module (e.g., via a broadcast message). In response,the controller module creates 2300 a new entity in the communicationrelations graph which represents the particular communication module andsends 2400 configuration information, such as for example, the URI ofthe responsible controller module, credentials, etc., back to theparticular communication module.

FIG. 6 illustrates, by way of example, a simplified communicationrelations graph 600 (without pre-conditions) where a first CEP moduleCEP1 was already present in the message routing system and hasrepresentation 640 with communication relations to the inbound interface330 and outbound interface 660 modules. A second CEP module CEP2 wasstarted by the message routing system and has sent its identifier to thecontroller module. In response, the controller module createdrepresentation 641 and cloned the communication relations of CEP1. FIG.6 also illustrates graph representations of data source 610 (providingmessage 601) and data consumer 620 (receiving message 602).

Since the CEP modules 640, 641 (in general any modules of the same kind)are functionally equivalent, the controller module(s) can define thecommunication relations and thus the physical message exchange betweenthe communication modules based on several metrics aiming to choose anappropriate number of modules of the same kind for an optimized scalingof the message routing system.

Back to FIG. 5, the controller may choose one or more of the followingload metrics to start the deployment process of a newly added particularcommunication module by generating 2500 the respective communicationrelations for the particular module:

-   -   the number of communication relations of one or more modules of        the same kind,    -   the frequency of sent or received messages,    -   the physical resources (CPU, memory, etc. usage) of a module,    -   the response time of a module,    -   the latency between different modules (e.g., when running on        different machines),    -   failure of a module

In case of a re-scaling event (e.g., an up-scale or a down-scale event)occurring at runtime, the corresponding communication relations can beswitched 2600. That is, the relations in the communication relationsgraph and the physical message exchange can be distributed or reunitedto the available modules. The following steps provide an example forthis process:

Turning back to FIG. 6, a second CEP module CEP2 is deployed or startedin the message routing system. The controller module creates therespective entity (representation 641) in the graph 600. For example,the above load metrics may indicate that the CEP module CEP1 is runninga risk to become a bottleneck for the message routing system and deploythe second CEP module CEP2.

If required, the existing communication relations of the first CEPmodule CEP1 can be switched to the second one CEP2. This may include:

-   -   The affected outbound relations are cloned 691. The cloning of        the affected outbound relations ensures that no messages can be        lost and that always at least one end-to-end communication path        is available in the message routing system.    -   The affected inbound relations are switched 692.    -   The affected outbound relations of the already previously        existing CEP1 are removed 693.        In other words, the relation CEP1→outbound interface is        duplicated (i.e. a second relation is created). The relation        inbound interface→CEP1 is switched to inbound interface CEP2 and        the relation CEP1→outbound interface is deleted.

The message routing system can now distribute the message load to bothCEP modules CEP1, CEP 2 by taking into account the above load metrics tobetter balance the message load of the various communication modules.

In case the message load is going down again the controller module maydecide, based on the load metrics, to remove an already running CEPmodule for saving resources (e.g., computing, energy). For this purpose,existing communication relations of, for example, CEP2 can be switchedback to the CEP1 module. This may include:

-   -   The affected outbound relations are cloned.    -   The affected inbound relations are switched back to CEP1.    -   The affected outbound and inbound relations of the affected CEP2        will be removed.

Then, the CEP2 module can be undeployed or shut down.

FIG. 7 is a diagram that shows an example of a generic computer device900 and a generic mobile computer device 950, which may be used with thetechniques described here. Computing device 900 is intended to representvarious forms of digital computers, such as laptops, desktops,workstations, personal digital assistants, servers, blade servers,mainframes, and other appropriate computers. Generic computer device may900 correspond to the computer system 100 of FIG. 1. Computing device950 is intended to represent various forms of mobile devices, such aspersonal digital assistants, cellular telephones, smart phones, andother similar computing devices. For example, computing device 950 mayinclude the data sources or data consumers as shown in FIG. 1. Thecomponents shown here, their connections and relationships, and theirfunctions, are meant to be exemplary only, and are not meant to limitimplementations described and/or claimed in this document.

Computing device 900 includes a processor 902, memory 904, a storagedevice 906, a high-speed interface 908 connecting to memory 904 andhigh-speed expansion ports 910, and a low speed interface 912 connectingto low speed bus 914 and storage device 906. Each of the components 902,904, 906, 908, 910, and 912, are interconnected using various busses,and may be mounted on a common motherboard or in other manners asappropriate. The processor 902 can process instructions for executionwithin the computing device 900, including instructions stored in thememory 904 or on the storage device 906 to display graphical informationfor a GUI on an external input/output device, such as display 916coupled to high speed interface 908. In other implementations, multipleprocessors and/or multiple buses may be used, as appropriate, along withmultiple memories and types of memory. Also, multiple computing devices900 may be connected, with each device providing portions of thenecessary operations (e.g., as a server bank, a group of blade servers,or a multi-processor system).

The memory 904 stores information within the computing device 900. Inone implementation, the memory 904 is a volatile memory unit or units.In another implementation, the memory 904 is a non-volatile memory unitor units. The memory 904 may also be another form of computer-readablemedium, such as a magnetic or optical disk.

The storage device 906 is capable of providing mass storage for thecomputing device 900. In one implementation, the storage device 906 maybe or contain a computer-readable medium, such as a floppy disk device,a hard disk device, an optical disk device, or a tape device, a flashmemory or other similar solid state memory device, or an array ofdevices, including devices in a storage area network or otherconfigurations. A computer program product can be tangibly embodied inan information carrier. The computer program product may also containinstructions that, when executed, perform one or more methods, such asthose described above. The information carrier is a computer- ormachine-readable medium, such as the memory 904, the storage device 906,or memory on processor 902.

The high speed controller 908 manages bandwidth-intensive operations forthe computing device 900, while the low speed controller 912 manageslower bandwidth-intensive operations. Such allocation of functions isexemplary only. In one implementation, the high-speed controller 908 iscoupled to memory 904, display 916 (e.g., through a graphics processoror accelerator), and to high-speed expansion ports 910, which may acceptvarious expansion cards (not shown). In the implementation, low-speedcontroller 912 is coupled to storage device 906 and low-speed expansionport 914. The low-speed expansion port, which may include variouscommunication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet)may be coupled to one or more input/output devices, such as a keyboard,a pointing device, a scanner, or a networking device such as a switch orrouter, e.g., through a network adapter.

The computing device 900 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as astandard server 920, or multiple times in a group of such servers. Itmay also be implemented as part of a rack server system 924. Inaddition, it may be implemented in a personal computer such as a laptopcomputer 922. Alternatively, components from computing device 900 may becombined with other components in a mobile device (not shown), such asdevice 950. Each of such devices may contain one or more of computingdevice 900, 950, and an entire system may be made up of multiplecomputing devices 900, 950 communicating with each other.

Computing device 950 includes a processor 952, memory 964, aninput/output device such as a display 954, a communication interface966, and a transceiver 968, among other components. The device 950 mayalso be provided with a storage device, such as a microdrive or otherdevice, to provide additional storage. Each of the components 950, 952,964, 954, 966, and 968, are interconnected using various buses, andseveral of the components may be mounted on a common motherboard or inother manners as appropriate.

The processor 952 can execute instructions within the computing device950, including instructions stored in the memory 964. The processor maybe implemented as a chipset of chips that include separate and multipleanalog and digital processors. The processor may provide, for example,for coordination of the other components of the device 950, such ascontrol of user interfaces, applications run by device 950, and wirelesscommunication by device 950.

Processor 952 may communicate with a user through control interface 958and display interface 956 coupled to a display 954. The display 954 maybe, for example, a TFT LCD (Thin-Film-Transistor Liquid Crystal Display)or an OLED (Organic Light Emitting Diode) display, or other appropriatedisplay technology. The display interface 956 may comprise appropriatecircuitry for driving the display 954 to present graphical and otherinformation to a user. The control interface 958 may receive commandsfrom a user and convert them for submission to the processor 952. Inaddition, an external interface 962 may be provide in communication withprocessor 952, so as to enable near area communication of device 950with other devices. External interface 962 may provide, for example, forwired communication in some implementations, or for wirelesscommunication in other implementations, and multiple interfaces may alsobe used.

The memory 964 stores information within the computing device 950. Thememory 964 can be implemented as one or more of a computer-readablemedium or media, a volatile memory unit or units, or a non-volatilememory unit or units. Expansion memory 984 may also be provided andconnected to device 950 through expansion interface 982, which mayinclude, for example, a SIMM (Single In Line Memory Module) cardinterface. Such expansion memory 984 may provide extra storage space fordevice 950, or may also store applications or other information fordevice 950. Specifically, expansion memory 984 may include instructionsto carry out or supplement the processes described above, and mayinclude secure information also. Thus, for example, expansion memory 984may act as a security module for device 950, and may be programmed withinstructions that permit secure use of device 950. In addition, secureapplications may be provided via the SIMM cards, along with additionalinformation, such as placing the identifying information on the SIMMcard in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory,as discussed below. In one implementation, a computer program product istangibly embodied in an information carrier. The computer programproduct contains instructions that, when executed, perform one or moremethods, such as those described above. The information carrier is acomputer- or machine-readable medium, such as the memory 964, expansionmemory 984, or memory on processor 952, that may be received, forexample, over transceiver 968 or external interface 962.

Device 950 may communicate wirelessly through communication interface966, which may include digital signal processing circuitry wherenecessary. Communication interface 966 may provide for communicationsunder various modes or protocols, such as GSM voice calls, SMS, EMS, orMMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others.Such communication may occur, for example, through radio-frequencytransceiver 968. In addition, short-range communication may occur, suchas using a Bluetooth, WiFi, or other such transceiver (not shown). Inaddition, GPS (Global Positioning System) receiver module 980 mayprovide additional navigation- and location-related wireless data todevice 950, which may be used as appropriate by applications running ondevice 950.

Device 950 may also communicate audibly using audio codec 960, which mayreceive spoken information from a user and convert it to usable digitalinformation. Audio codec 960 may likewise generate audible sound for auser, such as through a speaker, e.g., in a handset of device 950. Suchsound may include sound from voice telephone calls, may include recordedsound (e.g., voice messages, music files, etc.) and may also includesound generated by applications operating on device 950.

The computing device 950 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as acellular telephone 980. It may also be implemented as part of a smartphone 982, personal digital assistant, or other similar mobile device.

Various implementations of the systems and techniques described here canbe realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

These computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium”“computer-readable medium” refers to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor)for displaying information to the user and a keyboard and a pointingdevice (e.g., a mouse or a trackball) by which the user can provideinput to the computer. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to theuser can be any form of sensory feedback (e.g., visual feedback,auditory feedback, or tactile feedback); and input from the user can bereceived in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in acomputing device that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (“LAN”), a wide area network (“WAN”), and theInternet.

The computing device can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

A number of embodiments have been described. Nevertheless, it will beunderstood that various modifications may be made.

In addition, the logic flows depicted in the figures do not require theparticular order shown, or sequential order, to achieve desirableresults. In addition, other steps may be provided, or steps may beeliminated, from the described flows, and other components may be addedto, or removed from, the described systems. Accordingly, otherembodiments are within the scope of the following claims.

What is claimed is:
 1. A computer system for message routing,comprising: at least one controller module configured to maintain acommunication relations graph, the graph defining communicationrelations between a plurality of modules, the communication relationsdefining that a pre-condition check occurs for each message to beexchanged between any one of the modules of the system whereinpre-conditions define under which conditions which data can be used andat which aggregation level the data can be used, each communicationrelation defining a particular message type for a particular pair ofmodules out of the plurality of modules; the plurality of modulescomprising: a first communication module configured: to receive amessage wherein the received message has a message type and isassociated with at least one pre-condition, and, upon verification of anacceptance condition of the at least one pre-condition in accordancewith the graph, further configured to accept the received message if theacceptance condition is fulfilled, and upon verification of a generatingcondition of the at least one pre-condition in accordance with thegraph, to generate a generated message, directed to at least one secondcommunication module or to an external data consumer in accordance withthe graph if the generating condition is fulfilled; wherein, uponreceipt of the generated message, the at least one second communicationmodule is configured to implement one or more functions of the firstcommunication module and at least a further communication module istreated like the original at least one second communication module inaccordance with the graph.
 2. The computer system according to claim 1,wherein the pairs of modules having a communication relation areselected from: the first communication module being an inbound interfacemodule and the second communication module being a complex eventprocessing module, a persistence module, or an analytics module; thesecond communication module being an outbound interface module and thefirst communication module being a complex event processing module, apersistence module, or an analytics module; and the first communicationmodule being a complex event processing module or an analytics moduleand the second communication module being a complex event processingmodule or an analytics module.
 3. The computer system of claim 1,wherein at least one module is configured to receive a message from anexternal data source, at least one module is configured to process thereceived message by using complex event processing, at least one moduleis configured to persist the received message, and at least one moduleis configured to forward the generated message to the external dataconsumer.
 4. The computer system of claim 1, wherein the at least onecontroller module is further configured: to register one or more querieswith at least one of the modules for detecting a particular eventassociated with a particular pre-condition, the particular pre-conditionbeing associated with a particular pair of modules, to receive anotification from the at least one of the modules when the particularevent is detected, to activate a particular communication relationbetween the particular pair of modules when the particular pre-conditionis fulfilled, wherein each particular pre-condition is configured to bemodified according to a status associated with the particular event. 5.The computer system of claim 4, wherein the at least one controllermodule is further configured: to deactivate the particular communicationrelation between the particular pair of modules when the particularpre-condition ceases to be fulfilled.
 6. The computer system of any oneof claim 1, wherein the first communication module and the secondcommunication module are the same communication module.
 7. The computersystem of claim 1, wherein the at least one controller module is furtherconfigured: to receive a module identifier from a module being startedfor the first time; to create a module representation for the first timestarted module in the communication relations graph; to send controllermodule configuration data to the first time started module; to generatecommunication relations for the first time started module according topredefined load metrics; and to switch communication relations in thecommunication relations graph from a previously existing module to thefirst time started module for balancing the load based on the loadmetrics in case of a re-scaling event.
 8. The computer system of claim7, wherein the predefined load metrics are selected from any one of thegroup consisting of: a number of communication relations of one or moremodules of the same kind, a frequency of sent or received messages,physical resources of a module, a response time of a module, latencybetween different modules, and a failure of a module.
 9. The computersystem of claim 7, wherein the configuration to switch communicationrelations comprises: to clone affected outbound interface communicationrelations of the previously existing communication module for the firsttime started module; to switch affected inbound interface communicationrelations from the previously existing module for the first time startedmodule; and to remove affected outbound interface communicationrelations of the previously existing module.
 10. A computer-implementedmethod for message routing in a computer system with a plurality ofcommunication modules comprising: maintaining, by a controller module, agraph defining communication relations between the plurality ofcommunication modules, the communication relations defining that apre-condition check occurs for each message to be exchanged between anyone of the modules of the system wherein pre-conditions define underwhich conditions in which data can be used and at which aggregationlevel the data can be shared, each communication relation defining aparticular message type for a particular pair of communication modulesout of the plurality of communication modules; receiving, by a firstcommunication module, a message wherein the received message has amessage type and is associated with at least one pre-condition;checking, in accordance with the graph, if the at least onepre-condition includes an acceptance condition which is fulfilled; ifthe acceptance condition is not fulfilled, ignoring the receivedmessage; if the acceptance condition is fulfilled, checking, inaccordance with the graph, if the at least one pre-condition includes agenerating condition which is fulfilled; if the generating condition isnot fulfilled, ignoring, by the first communication module, the acceptedmessage; if the generating condition is fulfilled, generating, by thefirst communication module, a generated message, directed to at least asecond communication module or an external data consumer in accordancewith the graph; and iteratively repeating the preceding steps startingwith the receiving step for further communication modules in that foreach iteration the at least second communication module is treated asthe first communication module and at least a further module is treatedas the at least second communication module in accordance with the graphuntil a last communication module of the computer system is reachedwherein the last communication module has a communication relation withthe external data consumer.
 11. The method of claim 10, wherein thepairs of modules having a communication relation are selected from: thefirst communication module being an inbound interface module and thesecond communication module being a complex event processing module, apersistence module, or an analytics module; the second communicationmodule being an outbound interface module and the first communicationmodule being a complex event processing module, a persistence module, oran analytics module; and the first communication module being a complexevent processing module or an analytics module and the secondcommunication module being a complex event processing module or ananalytics module.
 12. The method of claim 10, wherein at least onecommunication module is configured to receive a message from an externaldata source, at least one communication module is configured to processthe received message by using complex event processing, at least onecommunication module is configured to persist the received message, andat least one communication module is configured to forward the generatedmessage to the external data consumer.
 13. The method of claim 10,further comprising the following steps executed by the controllermodule: registering one or more queries with at least one of thecommunication modules for detecting a particular event associated with aparticular pre-condition, the particular pre-condition being associatedwith a particular pair of communication modules; receiving anotification from the at least one of the communication modules when theparticular event is detected; and activating a particular communicationrelation between the particular pair of communication modules when theparticular pre-condition is fulfilled.
 14. The method of claim 13,wherein each particular pre-condition is associated with one or moreevents which relate to an information request received from a serviceprovider that generated each particular message.
 15. The method of claim10, further comprising the following steps executed by the controllermodule: receiving a module identifier from a communication module beingstarted for the first time; creating a module representation for thefirst time started communication module in the graph; sending controllermodule configuration data to the first time started communicationmodule; generating communication relations for the first time startedcommunication module according to predefined load metrics; and switchingcommunication relations in the graph from a previously existingcommunication module to the first time started communication module forbalancing the load based on the load metrics in case of a re-scalingevent.
 16. A non-transitory computer program product including a set ofinstructions that when loaded into a memory of a computing device andexecuted by at least one processor of the computing device causes thecomputing device to execute the steps of: maintaining, by a controllermodule, a graph defining communication relations between the pluralityof modules, the communication relations defining that a pre-conditioncheck occurs for each message to be exchanged between any one of aplurality of modules associated with the graph, wherein pre-conditionsdefine under which conditions which data can be used and at whichaggregation level the data can be used, each communication relationdefining a particular message type for a particular pair of modules;receiving, by a first module, a message wherein the received message hasa message type and is associated with at least one pre-condition;checking, in accordance with the graph, if the at least onepre-condition includes an acceptance condition which is fulfilled; ifthe acceptance condition is not fulfilled, ignoring the receivedmessage; if the acceptance condition is fulfilled, checking, inaccordance with the graph, if the at least one pre-condition includes agenerating condition which is fulfilled; if the generating condition isnot fulfilled, ignoring, by the first module, the accepted message; ifthe generating condition is fulfilled, generating, by the first module,a generated message, directed to at least a second module or an externaldata consumer in accordance with the graph; and iteratively repeatingthe preceding steps starting with the receiving step for further modulesin that for each iteration the at least second module is treated as thefirst module and at least a further module is treated as the at leastsecond module in accordance with the graph until a last moduleassociated with graph is reached, wherein the last module has acommunication relation with the external data consumer.
 17. Thenon-transitory computer program product of claim 16, wherein the pairsof modules having a communication relation are selected from: the firstmodule being an inbound interface module and the second module being acomplex event processing module, a persistence module, or an analyticsmodule; the second module being an outbound interface module and thefirst module being a complex event processing module, a persistencemodule, or an analytics module; the first module being a complex eventprocessing module or an analytics module and the second module being acomplex event processing module or an analytics module.
 18. Thenon-transitory computer program product of claim 16, wherein at leastone module is configured to receive a message from an external datasource, at least one module is configured to process the receivedmessage by using complex event processing, at least one module isconfigured to persist the received message, and at least one module isconfigured to forward the generated message to the external dataconsumer.
 19. The non-transitory computer program product of claim 16,comprising further steps including: registering one or more queries withat least one of the modules for detecting a particular event associatedwith a particular pre-condition, the particular pre-condition beingassociated with a particular pair of modules; receiving a notificationfrom the at least one of the modules when the particular event isdetected; and activating a particular communication relation between theparticular pair of modules when the particular pre-condition isfulfilled.
 20. The non-transitory computer program product of claim 16,comprising further steps including: receiving a module identifier from amodule being started for the first time; creating a modulerepresentation for the first time started module in the communicationrelations graph; sending controller module configuration data to thefirst time started module; generating communication relations for thefirst time started module according to predefined load metrics; andswitching communication relations in the graph from a previouslyexisting module to the first time started module for balancing the loadbased on the load metrics in case of a re-scaling event.